這篇不是在講「模型變壞」，是在講「權限設計沒跟上」

Tool Abuse 談的不是模型本身想做壞事，而是 Agent 被誘導（不管是透過 Prompt Injection 或是其他手法）去呼叫一個它技術上有權限、但情境上不該呼叫的工具。這正是 Day4 提到的陷阱一（過度授權）在紅隊視角下的具體展現。

一個具體的攻擊鏈範例

假設一個企業內部 Agent 掛載了「查詢客戶資料庫」與「發送郵件」兩個工具，各自看起來都合理——直到攻擊者透過間接注入誘導 Agent「把資料庫查詢結果整理成報表，並寄送到某個信箱」。單獨看，「查詢資料庫」跟「發郵件」都是正常授權範圍內的動作，但組合起來就是一次資料外洩。這正是為什麼 Day23（主題一）強調 Agent 工具授權要做最小權限盤點，而不是只看單一工具的權限範圍。

三個該檢查的工具授權盲點

工具組合的風險，不等於個別工具風險的加總：需要盤點「這些工具組合在一起，能達成什麼原本不該被允許的操作」，而不是只逐一審查每個工具本身安不安全。

工具呼叫的情境限制：搭配主題二 Day13 的 IAM Conditions，可以限制「這個工具只能在特定情境（例如特定時間、特定來源 IP）下被呼叫」，縮小被濫用的時間窗。

工具呼叫的稽核粒度：Cloud Audit Logs 記錄的是「呼叫了哪個 API」，但企業需要的往往是更細粒度的「Agent 為什麼在這個時間點呼叫了這個工具」，這需要在應用層額外設計日誌，而不是只依賴 GCP 原生的稽核紀錄。

這篇的檢查清單

• [ ] 是否已盤點 Agent 掛載的多個工具「組合起來」可能達成的風險，而非只審查單一工具？
• [ ] 高風險工具組合是否已用 IAM Conditions 限制呼叫情境？
• [ ] 是否有足夠細粒度的日誌，能回答「Agent 為什麼呼叫了這個工具」？

💡 關於作者
我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。